home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 6230 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.1 KB  |  70 lines
  1. Path: news.connect.net!usenet
  2. From: tomw@intelligraphics.com
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Modern "Effecient" Compilers
  5. Date: 11 Feb 1996 23:19:08 GMT
  6. Organization: Connection Technologies
  7. Message-ID: <4flthc$a9m@dallas1.connect.net>
  8. References: <662_9602110059@csource.blaze.net.au>
  9. Reply-To: tomw@intelligraphics.com
  10. NNTP-Posting-Host: igxtest.intelligraphics.com
  11. X-Newsreader: IBM NewsReader/2 v1.2
  12.  
  13. In <662_9602110059@csource.blaze.net.au>, David.Powell@f309.n632.z3.fidonet.org (David Powell) writes:
  14. >I would just like to mention something I noticed while compiling a "zero
  15. >length" (ie consisting only of the line main(){} ) cpp file in BC++ 4.52. 
  16. >I ensured that all RTTI, exceptions etc were off, and used the
  17. >optmize(size) style for my executable and code nodes of my project.  Yet
  18. >despite this, and only linking the run-time libraries, my small memory
  19. >model application took up 28kb.  Changing to tiny reduced the executable
  20. >size to 6kb.  By not linking in the run-time libraries I managed to produce
  21. >a 500 byte executable, although it crashed of course.  My question is, why
  22. >does 28k of rubbish get linked into my executable when I am making no
  23. >external references. (I have all debugging off of course).  I thought that
  24. >only code which resolved external references is linked in.  Does anybody no
  25. >why this problem occurs, or ways of getting around it without rewriting
  26. >lots of code, I would be most grateful if u would post a reply.  It is
  27. >quite embarrassing when friends using only the "inferior" Turbo Pascal
  28. >6.0/7.0 compiler can produce 1k files without tweaking anything.  Are the
  29. >compiler writers of today too willing to sacrifice performance for good
  30. >engineering principals?
  31.  
  32. The 28K you're seeing is caused partly by the startup code.  This should be
  33. in source/startup/c0x.asm in your Borland tree, assuming they still ship it
  34. (I haven't looked lately, but they should).  The startup code does things
  35. like copy command-line arguments out of the PSP, set up some interrupt
  36. handling stuff, and miscellany which I've forgotten.  I expect some of it is
  37. also coming from class/variable instances which may be referenced by the
  38. startup code or are simply always there.  If you want to reduce your code
  39. to the bare nubbin, take pieces out of c0*.asm.  Just be aware of what you
  40. are doing so that if your program needs command-line parameters for instance
  41. you can stick that part back in.
  42.  
  43. Most important, though, don't be embarrassed about it.  Turbo Pascal has
  44. long been very heavily optimized to generate small, fast code and link in
  45. only what absolutely has to be linked in.  It is a one-vendor technology; 
  46. they can do this.  C++ is a large, complex language with features that Pascal 
  47. doesn't have.  Plus, most linkers have relatively poor resolution.  If a C++
  48. object module with 10 functions is put into a library, and only one of those
  49. functions is ever called in a program, most linkers include all 10 functions
  50. in the executable.  This hopefully will change in the future, as this can be
  51. a pretty big hit on executable size.  (Although it seems that nobody cares
  52. much to produce small, tight code anymore.)
  53.  
  54. In short, this is a bit of a "who cares?" matter.  Let your friends brag.  10
  55. years from now, Turbo Pascal will be a dead and buried product, and
  56. your friends will have had to move on to another language.  C++ will still
  57. almost certainly be going strong.
  58.  
  59. +---------------------------------------------------------------------------+
  60. + Tom Wheeler                          | Member NRA, NMRA                   +
  61. + tomw@intelligraphics.com             | OS/2 user, C++ programmer          +
  62. + ------------------------------------------------------------------------- +
  63. + Postmodernism is the refusal to think.  Deconstructionism is the refusal  +
  64. + to believe that anyone else can either.                                   +
  65. +---------------------------------------------------------------------------+
  66. + Use or reproduction of this document or the author's email address for    +
  67. + commercial purposes without the author's permission is prohibited.        +
  68. +---------------------------------------------------------------------------+
  69.  
  70.